The evolvement of communication technology and user terminals has enabled versatile communication possibilities. The number of procedures to be carried out by a wireless terminal device, such as a mobile station or a personal digital assistant (PDA), has increased considerably as a result of advances in mobile communication technology. For example, a mobile station is no longer used for calls exclusively, but the mobile station enables information to be processed and presented in a more and more versatile manner.
Different software applications for versatile communications have also evolved alongside. The introduction of hardware and software independent wireless Java programming language, and especially J2ME (Java 2 Platform, Micro Edition) technology, which is suitable for the range of extremely tiny commodities such as smart cards or a pager all the way up to the appliances as powerful as a computer, has accelerated the usage of web services via different applications called MIDlets. The MIDlets are applications designed to run on wireless Java-enabled devices, and they can access objects across the Internet via URL (Uniform Resource Locator) addresses as easily as on a local file system. Usually, the MIDlets conform to Mobile Information Device Profile (MIDP) specification that specifies the architecture and the associated application programming interfaces (API) required for enabling an open third-party application development environment for mobile information devices. The MIDP, combined with a connected limited device configuration (CLDC), is the Java runtime environment for today's compact mobile information devices.
The MIDP 1.0 specified only one way to start a MIDlet: manual activation by the user. This lack of choices limited the range of services that a MIDlet could provide; in particular, there was no way to receive new contents automatically. To overcome this, the MIDP 2.0 specification introduced two new mechanisms to launch a MIDlet: in response to an incoming connection or at a scheduled time, i.e. without user initiation. These mechanisms make whole new classes of services possible by enabling receiving and acting on data asynchronously. The new mechanisms utilize an application management system AMS, in Java environment also called JAM, which is responsible for each application's life-cycle (installation, activation, execution, and removal), and especially a component called Push Registry in the AMS. When a MIDlet is active (running), the MIDlet itself is responsible for all communication events, such as setting up and monitoring inbound connections. When a MIDlet is not active, it can request the AMS to monitor inbound connections on behalf of the MIDlet and when an inbound connection occurs, the AMS activates the MIDlet to handle the inbound connection.
In MIDP, inbound connections may be message-based, such as short messages, stream-based, such as a TCP socket, or packet-based, such as a datagram. The message-based inbound connections may buffer a pushed message. However, when an inbound connection is not message-based the MIDlet must open the connection promptly because a connecting party may start sending data immediately after the connection has been set up. One of the problems associated with the above arrangement is that it may take some time before the MIDlet is actually auto-launched and able to start to communicate with the connecting party, only after which data can be received. The delay may be quite significant, especially if a user approval is needed to auto-launch the MIDlet. Situations may then exist in which the connecting party starts to send data although the receiving MIDlet is not yet running, and thus cannot receive the data.